openUBMC RAID南向部件驱动特性设计说明书 ​

Copyright © 2026 openUBMC Community

您对"本文档"的复制，使用，修改及分发受木兰宽松许可证, 第2版协议(以下简称"MulanPSL2")的约束。 为了方便用户理解，您可以通过访问https://license.coscl.org.cn/MulanPSL2了解MulanPSL2的概要 (但不是替代)。 MulanPSL2的完整协议内容您可以访问如下网址获取：https://license.coscl.org.cn/MulanPSL2。

改版记录

目录 ​

1. 特性概述
   1.1 目的
   1.2 范围
   1.3 特性需求列表

2. 需求场景分析
   2.1 特性需求来源与价值概述
   2.2 特性场景分析
   2.3 特性影响分析

3. 特性/功能实现原理
   3.1 目标
   3.2 总体方案

4. Use Case一实现：RAID卡管理南向驱动规范实现
   4.1 设计思路
   4.2 约束条件
   4.3 详细实现
   4.4 关键接口

5. Use Case二实现：RAID卡管理南向驱动CSR配置
   5.1 设计思路
   5.2 约束条件
   5.3 详细实现
   5.4 关键接口

6. Use Case三实现：RAID卡管理南向驱动CSR加载
   6.1 设计思路
   6.2 约束条件
   6.3 详细实现
   6.4 关键接口

7. Use Case四实现：RAID卡管理适配南向驱动
   7.1 设计思路
   7.2 约束条件
   7.3 详细实现
   7.4 关键接口

8. Use Case五实现：南向RAID卡管理DFX功能兼容
   8.1 设计思路
   8.2 约束条件
   8.3 详细实现
   8.4 关键接口

9. Use Case六实现：南向RAID卡管理北向功能兼容
   9.1 设计思路
   9.2 约束条件
   9.3 详细实现
   9.4 关键接口

10. Use Case七实现：一键日志收集导出RAID南向设备树信息
    10.1 设计思路
    10.2 约束条件
    10.3 详细实现
    10.4 关键接口

11. 可靠性&可用性设计
    11.1 冗余设计
    11.2 故障管理
    11.3 过载控制设计

12. 安全&隐私&韧性设计
    12.1 安全威胁分析及设计
    12.2 隐私风险分析

13. 特性非功能性质量属性相关设计
    13.1 可测试性
    13.2 可服务性
    13.3 可演进性
    13.4 兼容性

14. 参考资料清单

表目录

表1：特性场景相关性分析
表2：特性需求列表
表3：南向驱动接口列表
表4：SML兼容接口函数指针列表
表5：北向接口功能验证项

图目录

图1：RAID南向部件驱动整体架构图
图2：CSR加载策略图
图3：RAID管理适配南向驱动分层架构图
图4：南向驱动数据同步流程图
图5：CSR加载决策逻辑图
图6：北向功能兼容验证流程图
图7：DFX功能兼容验证流程图

1. 特性概述 ​

openUBMC RAID南向部件驱动特性旨在将RAID卡管理能力从应用层下沉至标准化的南向部件驱动框架，通过南向接口规范实现RAID卡、BBU、逻辑盘、物理盘、Expander等存储组件的统一管理。该特性新开发RAID南向驱动作为SML与设备树之间的适配层，将SML数据转换同步到设备树，实现存储管理的标准化和平台解耦。

本特性通过产业VPD打包CSR策略，支持同一BMC版本下灵活选择应用层管理（CSR1.0）或南向驱动管理（CSR2.0）两种模式，充分保证历史版本兼容性。同时，基于libsml_dev新库的开发，在保持上层应用接口不变的前提下，将底层实现切换至设备树访问，实现平滑迁移。

1.1 目的 ​

本文档基于openUBMC RAID南向部件驱动需求分析，对该特性的功能进行详细设计，明确系统架构、接口规范和实现方案，作为后续软件开发人员、测试人员和硬件集成工程师的技术指导文档。

文档详细描述了南向驱动规范实现、CSR配置与加载策略、应用层适配、北向功能兼容、DFX功能兼容以及可定位性增强等核心组件的设计与实现，为开发团队提供全面的技术规范和实现指南。

1.2 范围 ​

RAID南向部件驱动特性主要包含以下功能模块和适用场景：

核心功能模块：

• 南向驱动规范实现：基于南向接口规范实现RAID存储组件的管理接口
• 南向驱动CSR配置：按照南向接口规范从RAID卡厂商维度实现南向组件CSR
• 南向驱动CSR加载：通过VPD打包策略区分应用层管理与南向驱动管理
• RAID管理适配南向驱动：libsml_dev库开发，设备树SR兼容处理，SML兼容接口适配
• 北向功能兼容：Web/Redfish/CLI/SNMP/IPMI 等北向接口与历史功能保持一致
• DFX功能兼容：告警、传感器等历史功能继承兼容
• 一键日志收集：导出RAID南向设备树信息，提升可定位性

适用场景分析：

1.3 特性需求列表 ​

RAID南向部件驱动特性需求清单：

2. 需求场景分析 ​

2.1 特性需求来源与价值概述 ​

需求来源背景：

openUBMC RAID南向部件驱动特性需求来源于存储管理架构标准化和平台解耦的核心诉求：

1. 应用层RAID管理强耦合问题：

   • 历史RAID卡管理依赖应用层直接调用SML（Storage Management Library）
   • 应用层与具体RAID卡厂商SDK强绑定，导致扩展性差
   • 缺乏统一的南向标准接口，不同厂商RAID卡适配成本高

2. 南向驱动架构规范化需求：

   • 产业推进BMC南向接口规范，要求存储组件按标准接口实现
   • 需要将RAID卡管理能力以南向部件驱动形式注册到设备树
   • 应用层通过设备树访问RAID数据，实现管理面与驱动面解耦

3. 历史兼容性与平滑迁移需求：

   • 存量产品已基于CSR1.0（应用层管理）部署，不能直接切换
   • 新产品需要支持CSR2.0（南向驱动管理）
   • 要求同一BMC版本同时支持两种管理模式，通过VPD打包策略灵活选择

4. 可定位性不足问题：

   • RAID下沉南向驱动后，资源协作接口数据均来自设备树同步
   • 当资源协作接口数据不满足预期时，需要能导出设备树信息辅助定位

5. 北向接口一致性诉求：

   • 网管、运维对 RAID 的访问多通过 Web、Redfish、CLI、SNMP、IPMI 等北向通道完成
   • 管理路径改为设备树+资源协作后，各北向接口的语义、能力须与历史版本一致，避免业务脚本与网管系统行为差异

价值概述：

RAID南向部件驱动特性通过标准化设计，全面提升了RAID卡管理能力：

• 架构标准化：基于南向接口规范实现，提升RAID卡管理的标准化水平
• 平台解耦：RAID管理从应用层下沉到南向驱动，实现平台与管理面解耦
• 灵活选择：VPD打包策略支持两种管理模式灵活切换，兼顾新老产品需求
• 历史兼容：libsml_dev库保持上层接口不变，实现平滑迁移
• 北向无感一致：各北向接口（Web/Redfish/CLI/SNMP/IPMI）的 RAID 管理功能与历史版本保持一致
• 可定位性强：一键日志导出设备树信息，大幅提升问题定位效率

2.2 特性场景分析 ​

RAID南向部件驱动特性的业务使用场景主要涵盖存储设备管理的全生命周期：

主要应用场景：

1. 南向驱动管理场景：新产品使用CSR2.0，通过南向驱动管理RAID卡
2. 应用层管理兼容场景：历史产品使用CSR1.0，沿用应用层管理方式
3. 北向接口兼容场景：CSR2.0 下通过资源协作接口对接设备树后，Web/Redfish/CLI/SNMP/IPMI 等北向通道的 RAID 查询、配置、告警呈现与历史行为一致
4. 存储信息查询场景：通过设备树获取RAID控制器、逻辑盘、物理盘等信息
5. DFX告警监控场景：继承历史告警传感器功能，确保功能无缺失
6. 问题定位场景：一键日志导出RAID设备树信息辅助问题定位

关键场景分析：

2.3 特性影响分析 ​

RAID南向部件驱动特性作为openUBMC存储管理架构的重大演进，对系统架构产生深远影响。

系统位置与周边接口：

• 南向驱动层：新增RAID南向驱动，作为SML与设备树之间的适配层
• 应用层：新开发libsml_dev库，对接设备树替代原有sml_base
• CSR配置：新增南向驱动CSR（5.0），与历史应用层CSR（3.0）并存
• 设备树：新增RAID相关南向模型节点，承载RAID管理数据
• 北向接口层：各北向协议（Web/Redfish/CLI/SNMP/IPMI）经资源协作接口获取 RAID 数据，须与历史 CSR1.0 路径在功能与数据语义上保持一致
• 日志收集：扩展一键日志收集功能，增加RAID设备树信息导出

关键约束与限制：

• 同一BMC版本需同时支持CSR1.0（应用层管理）和CSR2.0（南向驱动管理）
• libsml_dev库需保持与原有SML接口完全兼容，上层调用不做任何修改
• Web、Redfish、CLI、SNMP、IPMI 等北向接口的 RAID 管理功能与历史版本保持一致，无任何功能缺失
• 告警、传感器等DFX功能切换后与历史保持一致，无任何功能缺失
• 南向驱动接口以"T CESA 服务器管理南向接口技术要求"为准

3. 特性/功能实现原理 ​

3.1 目标 ​

RAID南向部件驱动特性设计目标是构建一个标准化、可扩展、向后兼容的RAID存储管理驱动框架：

主要目标：

1. 规范化：基于南向接口规范实现，满足产业标准要求
2. 解耦：RAID管理面与驱动面解耦，通过设备树交换数据
3. 兼容：历史管理模式（CSR1.0）与新南向驱动模式（CSR2.0）并存
4. 平滑迁移：libsml_dev库保持SML接口不变，上层零改造
5. 北向一致：Web/Redfish/CLI/SNMP/IPMI 等北向通道的 RAID 管理行为与历史版本一致
6. 可定位：一键日志导出设备树信息，提升问题定位能力

技术规格：

• 支持双RAID卡同时加载，挂接30+硬盘，同时增加2张i2c网卡，数据更新无异常
• 支持3张RAID卡同时加载，挂接30+硬盘，同时增加1张i2c网卡，数据更新无异常
• 告警、传感器等DFX功能与历史版本保持一致
• 各北向接口（含 SNMP、IPMI）的 RAID 相关功能与历史版本一致，可测试、可对比验证
• CSR1.0和CSR2.0均需验证，历史功能保持一致

3.2 总体方案 ​

系统概述：

RAID南向部件驱动特性通过分层架构实现RAID卡管理的南向化改造。南向驱动层作为SML与设备树的适配层，将SML获取的RAID数据转换并同步到设备树；应用层通过新开发的libsml_dev库访问设备树数据，保持上层接口不变。VPD打包策略实现两种管理模式的灵活切换。北向管理面（Web/Redfish/CLI/SNMP/IPMI）仍通过资源协作接口呈现与管理 RAID 数据，在 CSR2.0 下与设备树、南向驱动数据对齐，并须与历史 CSR1.0 行为一致。

架构设计原则：

1. 分层解耦：南向驱动、设备树、应用层与北向协议层严格分层，各层通过标准接口交互
2. 接口兼容：libsml_dev库完全兼容SML函数指针接口，上层零改造
3. CSR策略化：通过VPD打包不同CSR文件实现管理模式按机型灵活选择
4. 北向一致：各北向通道经资源协作接口与设备树数据同源，对网管/脚本保持与历史版本一致的功能与语义
5. DFX继承：新架构完整继承历史告警、传感器等DFX能力

图1：RAID南向部件驱动整体架构图

图2：CSR加载策略图

4. Use Case一实现：RAID卡管理南向驱动规范实现 ​

4.1 设计思路 ​

基于最新南向驱动规范，实现RAID卡管理南向驱动的管理接口及协议，新开发RAID卡南向管理驱动作为SML与设备树之间的适配层，负责将SML获取的数据转换并同步到设备树，完成设置和获取等存储管理功能。

实现思路：

1. 南向驱动接口规范化：

   • 基于"T CESA 服务器管理南向接口技术要求"实现所有RAID存储组件的南向接口
   • 涵盖控制器、BBU、逻辑盘、物理盘、DiskArray、Expander等核心组件
   • 每个组件按照接口规范定义标准的管理接口、协议和数据模型

2. 南向驱动适配层开发：

   • 新开发RAID卡南向管理驱动，作为SML与设备树中间的适配层
   • 从SML获取RAID卡原始数据，按南向接口规范转换后写入设备树
   • 支持从设备树读取配置，通过SML下发到RAID卡执行

3. 存储组件全覆盖：

   • 控制器（Controller）：基础信息、能力集、状态、指标、设置、PHY等
   • BBU：状态信息
   • 逻辑盘（Volume）：策略、状态、设置、关联关系
   • 物理盘（Drive）：物理上下文、LED、接口、状态、指标、设置、关联
   • DiskArray：关联关系
   • Expander：物理上下文、状态、PHY及PHY指标

4.2 约束条件 ​

前提条件：

• SML库可正常加载并与RAID卡通信
• 设备树服务运行正常

规范约束：

• 南向驱动接口以"T CESA 服务器管理南向接口技术要求 草案.doc"为最终规范
• 接口名称和数据结构需严格遵循规范定义，不得自行扩展

性能要求：

• 双RAID卡同时加载，挂接30+硬盘，数据更新无异常
• 3张RAID卡同时加载，挂接30+硬盘，数据更新无异常

4.3 详细实现 ​

南向驱动接口组件列表：

图4：南向驱动数据同步流程图

4.4 关键接口 ​

南向驱动核心接口：

1. 控制器管理接口：注册、注销控制器南向驱动；获取控制器基础信息、能力、状态、指标
2. 物理盘管理接口：获取物理盘状态、指标、SMART信息；执行物理盘操作
3. 逻辑盘管理接口：获取逻辑盘信息、状态；执行逻辑盘操作和RAID配置操作
4. BBU管理接口：获取BBU状态信息
5. Expander管理接口：获取Expander信息、PHY指标；执行PHY误码诊断
6. 设备树写入接口：将转换后的RAID数据同步写入设备树对应节点

5. Use Case二实现：RAID卡管理南向驱动CSR配置 ​

5.1 设计思路 ​

按照南向接口规范要求，从RAID卡厂商维度实现到南向组件仓的CSR配置，为南向驱动管理模式（CSR2.0）提供完整的配置支撑。

实现思路：

1. 按厂商维度组织CSR：

   • 从RAID卡厂商维度划分南向驱动CSR，支持不同厂商RAID卡的差异化配置
   • 每种厂商RAID卡对应一套南向驱动CSR（5.0）配置文件

2. 南向组件仓实现：

   • 按照南向接口规范，在南向组件仓中实现RAID相关存储组件的CSR
   • 包含控制器、BBU、逻辑盘、物理盘、DiskArray、Expander等全部组件的CSR定义

3. 南向驱动CSR与历史CSR并存：

   • 南向驱动CSR（5.0）与历史应用层CSR（3.0）在代码仓中并存
   • 通过VPD打包策略决定实际加载哪种CSR

5.2 约束条件 ​

前提条件：

• 南向接口规范已定义，以"T CESA 服务器管理南向接口技术要求"为准
• RAID卡厂商信息明确，支持按厂商维度拆分CSR

兼容性要求：

• 南向驱动CSR（5.0）的新增不能影响历史应用层CSR（3.0）的加载和使用

6. Use Case三实现：RAID卡管理南向驱动CSR加载 ​

6.1 设计思路 ​

通过产业VPD打包RAID卡管理CSR的差异化策略，实现同一BMC版本按机型选择应用层管理（CSR1.0）或南向驱动管理（CSR2.0），确保新老产品无缝兼容。

实现思路：

1. VPD差异化打包策略：

   • CSR1.0（应用层管理）：VPD仅打包历史RAID卡CSR（3.0）文件，不打包南向驱动RAID卡管理CSR（5.0）
   • CSR2.0（南向驱动管理）：VPD不打包历史RAID卡CSR（3.0）文件，仅打包南向驱动RAID卡管理CSR（5.0）

2. 按CSR文件自动选择管理模式：

   • BMC启动时根据VPD中打包的CSR文件类型，自动加载对应的管理模式
   • 加载历史CSR（3.0）→ 走应用层管理路径
   • 加载南向驱动CSR（5.0）→ 走南向驱动管理路径

3. 机型差异化支持：

   • 不同机型通过VPD中CSR文件的差异实现管理模式的按机型定制
   • 无需修改BMC软件版本，仅通过VPD内容区分管理策略

6.2 约束条件 ​

前提条件：

• VPD打包工具支持按机型选择性打包CSR文件
• BMC启动时CSR加载逻辑支持5.0版本南向驱动CSR的识别和加载

互斥约束：

• 同一机型VPD中不能同时打包CSR1.0（3.0文件）和CSR2.0（5.0文件），两者互斥

兼容性要求：

• CSR1.0策略（仅打包3.0文件）下，历史所有功能与原有版本完全一致

6.3 详细实现 ​

图5：CSR加载决策逻辑图

VPD打包示例：

# CSR1.0策略（应用层管理机型）
VPD内容：
  - RAID_Controller_VendorA_3.0.csr   ✅ 打包
  - RAID_Controller_VendorA_5.0.csr   ❌ 不打包

# CSR2.0策略（南向驱动管理机型）
VPD内容：
  - RAID_Controller_VendorA_3.0.csr   ❌ 不打包
  - RAID_Controller_VendorA_5.0.csr   ✅ 打包

6.4 关键接口 ​

CSR加载核心接口：

1. VPD文件扫描接口：扫描VPD中的CSR文件，识别3.0或5.0版本
2. 管理模式选择接口：根据CSR文件版本选择对应的管理路径
3. CSR注册接口：将加载的CSR注册到对应管理框架

7. Use Case四实现：RAID卡管理适配南向驱动 ​

7.1 设计思路 ​

RAID卡管理适配南向驱动的核心是实现设备树SR兼容处理，通过新开发libsml_dev库对接设备树，同时兼容SML库原有接口，使上层应用在不修改任何代码的前提下，底层数据访问切换至设备树。

实现思路：

1. 设备树资源对象创建：

   • 根据设备树对象创建资源树对象并完成上树
   • RAID相关设备树节点映射为对应的资源树对象

2. libsml_dev库开发：

   • 应用层新开发libsml_dev库，用于替代原有sml_base
   • libsml_dev直接对接设备树，按照接口规范实现设置、获取等存储特性功能
   • 上层通过libsml_dev访问设备树数据，无需感知底层实现变化

3. SML接口兼容适配：

   • 保证应用层接口不变更，通过函数指针兼容原有SML接口
   • 具体函数指针指向libsml_dev的设备树实现，替换原有SML调用

图3：RAID管理适配南向驱动分层架构图

7.2 约束条件 ​

前提条件：

• 设备树服务运行正常，RAID南向驱动已完成数据同步
• libsml_dev库实现需覆盖所有SML函数指针接口，不能有遗漏

接口兼容要求：

• 应用层接口（函数指针定义）不做任何修改
• libsml_dev库需完整实现表4中所有函数指针的设备树版本

性能要求：

• 双RAID卡同时加载，挂接30+硬盘，同时增加2张i2c网卡，RAID卡、硬盘及网卡数据更新无异常
• 3张RAID卡同时加载，挂接30+硬盘，同时增加1张i2c网卡，RAID卡、硬盘及网卡数据更新无异常

兼容性要求：

• CSR1.0和CSR2.0均需验证，历史功能保持一致

7.3 详细实现 ​

资源树对象创建流程：

1. 南向驱动启动后将RAID数据同步到设备树节点
2. BMC资源管理框架监听设备树节点变化
3. 根据设备树对象类型创建对应的资源树对象（控制器、物理盘、逻辑盘等）
4. 完成资源树对象上树，供应用层通过资源协作接口访问

SML兼容接口函数指针列表（表4）：

7.4 关键接口 ​

libsml_dev库核心接口：

1. 初始化接口：初始化libsml_dev库，建立设备树访问连接
2. 函数指针注册接口：向上层注册所有SML兼容函数指针
3. 设备树读取接口：按接口规范从设备树读取RAID各组件数据
4. 设备树写入接口：将操作指令写入设备树，驱动南向驱动执行

8. Use Case五实现：南向RAID卡管理DFX功能兼容 ​

8.1 设计思路 ​

RAID卡管理切换到南向驱动模式后，需要确保原有的告警、传感器等DFX功能完整继承，与历史版本保持一致，无任何功能缺失。

实现思路：

1. 告警功能继承：

   • 验证南向驱动管理模式下，历史RAID卡告警配置能正常工作
   • RAID卡告警事件继续通过原有告警通道上报，与历史行为一致

2. 传感器功能继承：

   • 验证南向驱动管理模式下，历史RAID卡传感器配置能正常工作
   • RAID卡温度、电压等传感器数据继续通过原有传感器框架上报

3. 功能完整性验证：

   • 对照历史功能清单逐项验证南向驱动管理模式下的DFX功能
   • 确保告警、传感器等功能无遗漏、无差异

8.2 约束条件 ​

兼容性要求：

• 告警、传感器等功能与历史保持一致，无任何功能缺失
• CSR2.0（南向驱动管理）下的DFX功能表现需与CSR1.0（应用层管理）完全一致

8.3 详细实现 ​

告警配置验证项：

1. RAID控制器故障告警
2. 物理盘故障、预警告警
3. 逻辑盘降级、失效告警
4. BBU故障、低电量告警
5. Expander通信故障告警

传感器配置验证项：

1. RAID控制器温度传感器
2. 物理盘温度传感器
3. BBU电量/状态传感器
4. PHY误码计数传感器

图7：DFX功能兼容验证流程图

8.4 关键接口 ​

DFX兼容接口：

1. 告警配置读取接口：从CSR读取告警配置并验证完整性
2. 传感器配置读取接口：从CSR读取传感器配置并验证完整性
3. 历史功能对比接口：与历史版本DFX功能逐项对比验证

9. Use Case六实现：南向RAID卡管理北向功能兼容 ​

9.1 设计思路 ​

RAID卡管理切换到南向驱动模式后，需要确保原有的北向接口功能完整继承，Web、Redfish、CLI、SNMP、IPMI等各北向接口的RAID管理功能与历史版本保持一致，无任何功能缺失。

实现思路：

1. 北向接口全量兼容：

   • Web管理界面的RAID卡信息展示、操作功能与历史版本保持一致
   • Redfish接口的RAID相关资源（Storage、StorageController、Drive、Volume等）与历史版本保持一致
   • CLI命令行的RAID查询和操作命令功能与历史版本保持一致
   • SNMP的RAID相关MIB对象和告警Trap与历史版本保持一致
   • IPMI的RAID相关命令功能与历史版本保持一致

2. 数据通路适配：

   • 北向接口通过资源协作接口访问RAID数据，资源协作接口数据来源从SML直接获取切换为设备树同步
   • 确保资源协作接口在南向驱动管理模式下数据完整、准确，北向接口无感知

3. 功能完整性验证：

   • 对照历史北向接口功能清单逐项验证，确保南向驱动管理模式下各北向接口功能无遗漏、无差异

9.2 约束条件 ​

前提条件：

• RAID南向驱动已完成数据同步到设备树
• 资源协作接口已完成设备树数据对接

兼容性要求：

• 北向功能与历史保持一致，无任何功能缺失
• CSR2.0（南向驱动管理）下各北向接口表现需与CSR1.0（应用层管理）完全一致

9.3 详细实现 ​

表5：北向接口功能验证项

图6：北向功能兼容验证流程图

9.4 关键接口 ​

北向兼容接口：

1. Web接口：RAID卡信息查询、操作、固件升级等功能接口
2. Redfish接口：符合Redfish Storage Schema的标准资源接口
3. CLI接口：RAID查询和操作的命令行接口
4. SNMP接口：RAID相关MIB对象及告警Trap接口
5. IPMI接口：RAID相关传感器数据及SEL事件接口

10. Use Case七实现：一键日志收集导出RAID南向设备树信息 ​

10.1 设计思路 ​

RAID下沉南向驱动后，资源协作接口的数据均来源于设备树同步。当资源协作接口数据不满足预期时，需要通过导出设备树上的RAID相关信息辅助定位，提升可定位性。

实现思路：

1. 一键日志收集扩展：

   • 在现有一键日志收集功能中，新增RAID南向设备树信息的导出项
   • 导出设备树上所有RAID相关节点（Storage.*）的完整数据

2. 设备树信息格式化导出：

   • 将设备树上的RAID节点数据以可读格式（JSON或文本）导出
   • 包含控制器、BBU、逻辑盘、物理盘、Expander等所有组件的当前状态

3. 可定位性增强：

   • 导出数据包含libsml和适配器同步到设备树的所有字段
   • 方便对比资源协作接口数据与设备树原始数据，快速定位数据差异

10.2 约束条件 ​

前提条件：

• 一键日志收集功能正常运行
• RAID南向设备树节点存在（即BMC启动了南向驱动管理模式）

数据完整性要求：

• 导出数据需包含设备树上所有RAID相关节点的完整信息，不能遗漏

10.3 详细实现 ​

一键日志收集扩展：

1. 在日志收集任务列表中新增RAID设备树信息导出任务
2. 日志收集时触发设备树RAID节点遍历：
   • 遍历所有Storage.Controller及子节点
   • 遍历所有Storage.Drive节点
   • 遍历所有Storage.Volume节点
   • 遍历所有Storage.BBU节点
   • 遍历所有Storage.Expander节点
3. 将遍历结果格式化输出到日志文件
4. 日志文件打包到一键日志收集包中

10.4 关键接口 ​

日志收集接口：

1. 设备树遍历接口：遍历设备树上所有RAID相关节点
2. 数据序列化接口：将设备树节点数据序列化为可读格式
3. 日志写入接口：将序列化数据写入一键日志收集包
4. 任务注册接口：向一键日志收集框架注册RAID设备树导出任务

11. 可靠性&可用性设计 ​

11.1 冗余设计 ​

• 双管理模式：通过VPD CSR策略支持应用层管理（CSR1.0）和南向驱动管理（CSR2.0）并存，互为备选
• 接口兼容保障：libsml_dev库完全兼容SML函数指针接口，切换失败时可回退到历史路径
• 北向行为保障：资源协作与设备树数据异常时，北向接口应明确错误语义，避免静默返回与历史不一致的数据

11.2 故障管理 ​

• 数据同步异常检测：南向驱动同步RAID数据到设备树失败时记录错误日志并触发告警
• 设备树访问异常处理：libsml_dev库访问设备树失败时返回错误码，上层感知并处理
• 北向一致性检测：对比 CSR1.0 与 CSR2.0 同场景下北向输出，发现差异时记录日志并纳入回归
• DFX功能保障：告警传感器功能完整继承，南向驱动异常不影响历史DFX能力

11.3 过载控制设计 ​

• 多卡并发管理：支持3张RAID卡同时加载，30+硬盘并发管理，确保性能满足基线
• 设备树访问串行化：关键写操作串行化，避免并发写入设备树引发数据不一致
• 数据更新频率控制：静态数据降低更新频率，动态数据按需更新，减少设备树访问压力

12. 安全&隐私&韧性设计 ​

12.1 安全威胁分析及设计 ​

主要威胁：

• 未授权写入设备树RAID节点，篡改RAID配置
• 恶意触发RAID操作（物理盘操作、RAID配置操作等）
• 经北向通道（含 Web/Redfish/CLI/SNMP/IPMI）越权执行 RAID 敏感操作
• libsml_dev库加载劫持

防护措施：

• 设备树RAID节点写入需经过权限校验
• RAID操作接口及北向对应接口需经过已有的BMC鉴权、角色与审计机制
• libsml_dev库需经过完整性校验后加载

12.2 隐私风险分析 ​

该特性主要处理存储硬件设备信息，不涉及用户个人数据，隐私风险较低。

13. 特性非功能性质量属性相关设计 ​

13.1 可测试性 ​

• 验证双RAID卡同时加载，挂接30+硬盘，同时增加2张i2c网卡，数据更新无异常
• 验证3张RAID卡同时加载，挂接30+硬盘，同时增加1张i2c网卡，数据更新无异常
• CSR1.0和CSR2.0均需验证，历史功能保持一致
• 通过北向接口（Web/Redfish/CLI/SNMP/IPMI）验证 RAID 信息获取、配置与操作功能正常，并与历史版本行为逐项对比

13.2 可服务性 ​

• 一键日志收集时导出RAID南向设备树完整信息，辅助问题定位
• 南向驱动同步操作记录完整日志，包含数据来源、转换结果、同步状态
• 北向请求与资源协作数据变更可关联记录，便于对比 CSR1.0/CSR2.0 下用户可见行为

13.3 可演进性 ​

• libsml_dev库按接口规范设计，支持未来新增SML接口的扩展适配
• 南向驱动CSR（5.0）按厂商维度组织，支持新增厂商RAID卡的快速接入
• 设备树节点按南向接口规范定义，兼容规范后续版本演进

13.4 兼容性 ​

• 同一BMC版本同时支持CSR1.0（应用层管理）和CSR2.0（南向驱动管理）
• libsml_dev库完全兼容原有SML函数指针接口，上层应用零改造
• 告警、传感器等DFX功能与历史版本完全一致，无任何功能缺失
• Web、Redfish、CLI、SNMP、IPMI等北向接口功能与历史版本完全一致，无任何功能缺失
• 新增南向驱动CSR（5.0）不影响历史应用层CSR（3.0）的加载和使用

14. 参考资料清单 ​

1. T CESA 服务器管理南向接口技术要求 草案.doc
2. openUBMC南向部件驱动开发规范